A client computer can use a network, such as the Internet, to communicate with and identify other computers connected to the network. The client computer identifies a unique IP address for each of these other computers. The client computer may know the IP address of a computer, or may need to search for this IP address using the Domain Name System (DNS).
Sometimes there is reason to present a “block page” to a user, such as when the user attempts to browse to a site that is deemed inappropriate (malicious, gambling, porn, time-wasting, etc). Thus, these sites may be blocked, and the user is presented with a block page. However, sometimes the user needs to continue to a blocked site.
Traditional approaches for maintaining “whitelists,” which are, for example, lists of authorized IP addresses, require either distributing the whitelist updates through a central point, for example, a central datacenter running a database, or synchronizing the whitelist updates between web servers that handle a “continue to site” button, which may be included on a “block page.” Both of these approaches provide slow access for a user.
In the past, in an effort to speed up web browsing, browsers maintained their own DNS caches. However, these DNS caches do not always respect the Time to Live (TTL), which limits the time period an IP address is whitelisted, specified in a specific DNS record. This will cause problems for a user who wishes to continue to the blocked site, because the bad IP address is stuck in a user's browser cache, and the user will not be able to go to a web page corresponding to that bad IP address. In the past, service providers have asked users to explicitly flush the users' browser caches, or, when a user is not able to flush the browser cache, to simply quit and restart the browser. This requires the customer to take these measures themselves, and provides for a burdensome user experience. Thus, there is a need to automatically flush a user's browser cache without burdening the user.